bitcoinbook/ch04.asciidoc

[[ch04_keys_addresses]]
== Keys and Addresses

Alice wants to pay Bob, but the the thousands of Bitcoin full nodes who
will verify her transaction don't know who Alice or Bob are--and we want
to keep it that way to protect their privacy.  Alice needs to
communicate that Bob should receive some of her bitcoins without tying
any aspect of that transaction to Bob's real-world identity or to other
Bitcoin payments that Bob receives.  The method Alice uses must ensure
that only Bob can further spend the bitcoins he receives.

The original Bitcoin paper describes a very simple scheme for achieving
those goals, shown in <<pay-to-pure-pubkey>>.  A receiver like Bob
accepts bitcoins to a public key in a transaction which is signed by the
spender (like Alice).  The bitcoins which Alice is spending had been
previously received to one her public keys, and she uses the
corresponding private key to generate her signature.  Full nodes can
verify that Alice's signature commits to the output of a hash function
that itself commits to Bob's public key and other transaction details.

[[pay-to-pure-pubkey]]
.Transaction chain from original Bitcoin paper
image::images/mbc2_abin01.png["Transaction chain from original Bitcoin paper"]

We'll examine public keys, private keys, signatures, and hash functions
in the following sections, and then use all of them together to describe
the addresses used by modern Bitcoin software.

==== Public Key Cryptography and Cryptocurrency

((("keys and addresses", "overview of", "public key
cryptography")))((("digital currencies", "cryptocurrency")))Public key
cryptography was invented in the 1970s and is a mathematical foundation
for computer and information security.

Since the invention of public key cryptography, several suitable
mathematical functions, such as prime number exponentiation and elliptic
curve multiplication, have been discovered. These mathematical functions
are practically irreversible, meaning that they are easy to calculate in
one direction and infeasible to calculate in the opposite direction.
Based on these mathematical functions, cryptography enables the creation
of digital secrets and unforgeable digital signatures. Bitcoin uses
elliptic curve multiplication as the basis for its cryptography.

In bitcoin, we use public key cryptography to create a key pair that
controls access to bitcoin. The key pair consists of a private key
and--derived from it--a unique public key. The public key is used to
receive funds, and the private key is used to sign transactions to spend
the funds.

There is a mathematical relationship between the public and the private
key that allows the private key to be used to generate signatures on
messages. This signature can be validated against the public key without
revealing the private key.

When spending bitcoin, the current bitcoin owner presents her public key
and a signature (different each time, but created from the same private
key) in a transaction to spend those bitcoin. Through the presentation
of the public key and signature, everyone in the Bitcoin network can
verify and accept the transaction as valid, confirming that the person
transferring the bitcoin owned them at the time of the transfer.

[TIP]
====
((("keys and addresses", "overview of", "key pairs")))In most wallet
implementations, the private and public keys are stored together as a
_key pair_ for convenience. However, the public key can be calculated
from the private key, so storing only the private key is also possible.
====

[[private_public_keys]]
==== Private and Public Keys

((("keys and addresses", "overview of", "private and public key
pairs")))((("elliptic curve cryptography")))((("cryptography", "elliptic
curve cryptography")))A bitcoin wallet contains a collection of key
pairs, each consisting of a private key and a public key. The private
key (k) is a number, usually derived from a number picked at random.
From the private key, we
use elliptic curve multiplication, a one-way cryptographic function, to
generate a public key (K). From the public key (K), we use a one-way
cryptographic hash function to generate a Bitcoin address (A). In this
section, we will start with generating the private key, look at the
elliptic curve math that is used to turn that into a public key, and
finally, generate a Bitcoin address from the public key. The
relationship between private key, public key, and Bitcoin address is
shown in <<k_to_K_to_A>>.

[[k_to_K_to_A]]
.Private key, public key, and Bitcoin address
image::images/mbc2_0401.png["privk_to_pubK_to_addressA"]

.Why Use Asymmetric Cryptography (Public/Private Keys)?
****
((("cryptography", "asymmetric")))((("digital signatures", "asymmetric
cryptography and")))((("asymmetric cryptography")))Why is asymmetric
cryptography used in bitcoin? It's not used to "encrypt" (make secret)
the transactions. Rather, the useful property of asymmetric cryptography
is the ability to generate _digital signatures_. A private key can be
applied to the digital fingerprint of a transaction to produce a
numerical signature. This signature can only be produced by someone with
knowledge of the private key. However, anyone with access to the public
key and the transaction fingerprint can use them to _verify_ the
signature. This useful property of asymmetric cryptography makes it
possible for anyone to verify every signature on every transaction,
while ensuring that only the owners of private keys can produce valid
signatures.
****

[[private_keys]]
==== Private Keys

((("keys and addresses", "overview of", "private key
generation")))((("warnings and cautions", "private key protection")))A
private key is simply a number, picked at random. Ownership and control
over the private key is the root of user control over all funds
associated with the corresponding Bitcoin address. The private key is
used to create signatures that are required to spend bitcoin by proving
ownership of funds used in a transaction. The private key must remain
secret at all times, because revealing it to third parties is equivalent
to giving them control over the bitcoin secured by that key. The private
key must also be backed up and protected from accidental loss, because
if it's lost it cannot be recovered and the funds secured by it are
forever lost, too.

[TIP]
====
The bitcoin private key is just a number. You can pick your private keys
randomly using just a coin, pencil, and paper: toss a coin 256 times and
you have the binary digits of a random private key you can use in a
bitcoin wallet. The public key can then be generated from the private
key.
====

===== Generating a private key from a random number

The first and most important step in generating keys is to find a secure
source of entropy, or randomness. Creating a bitcoin key is essentially
the same as "Pick a number between 1 and 2^256^." The exact method you
use to pick that number does not matter as long as it is not predictable
or repeatable. Bitcoin software uses cryptographically-secure random
number generators to produce 256 bits of entropy (randomness).

More precisely, the private key can be any number between +0+ and +n -
1+ inclusive, where n is a constant (n = 1.1578 * 10^77^, slightly less
than 2^256^) defined as the order of the elliptic curve used in bitcoin
(see <<elliptic_curve>>). To create such a key, we randomly pick a
256-bit number and check that it is less than +n+. In programming terms,
this is usually achieved by feeding a larger string of random bits,
collected from a cryptographically secure source of randomness, into the
SHA256 hash algorithm, which will conveniently produce a 256-bit number.
If the result is less than +n+, we have a suitable private key.
Otherwise, we simply try again with another random number.

[WARNING]
====
((("random numbers", "random number generation")))((("entropy", "random
number generation")))Do not write your own code to create a random
number or use a "simple" random number generator offered by your
programming language. Use a cryptographically secure pseudorandom number
generator (CSPRNG) with a seed from a source of sufficient entropy.
Study the documentation of the random number generator library you
choose to make sure it is cryptographically secure. Correct
implementation of the CSPRNG is critical to the security of the keys.
====

The following is a randomly generated private key (k) shown in
hexadecimal format (256 bits shown as 64 hexadecimal digits, each 4
bits):

----
1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
----

[TIP]
====
The size of bitcoin's private key space, (2^256^) is an unfathomably
large number. It is approximately 10^77^ in decimal. For comparison, the
visible universe is estimated to contain 10^80^ atoms.
====

((("dumpprivkey command")))To generate a new key with the Bitcoin Core
client (see <<ch03_bitcoin_client>>), use the +getnewaddress+ command.
For security reasons it displays the public key only, not the private
key. To ask +bitcoind+ to expose the private key, use the +dumpprivkey+
command. The +dumpprivkey+ command shows the private key in a Base58
checksum-encoded format called the _Wallet Import Format_ (WIF), which
we will examine in more detail in <<priv_formats>>. Here's an example of
generating and displaying a private key using these two commands:

----
$ bitcoin-cli getnewaddress
1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
$ bitcoin-cli dumpprivkey 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
----

The +dumpprivkey+ command opens the wallet and extracts the private key
that was generated by the +getnewaddress+ command. It is not possible
for +bitcoind+ to know the private key from the public key unless they
are both stored in the wallet.

[TIP]
=====================================================================
The +dumpprivkey+ command does not generate a private key from a public
key, as this is impossible. The command simply reveals the private key
that is already known to the wallet and which was generated by the
+getnewaddress+ command.
=====================================================================

[role="pagebreak-before"]
You can also use the Bitcoin Explorer command-line tool (see
<<appdx_bx>>) to generate and display private keys with the commands
+seed+, +ec-new+, and +ec-to-wif+:

----
$ bx seed | bx ec-new | bx ec-to-wif
5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
----

[[pubkey]]
==== Public Keys

((("keys and addresses", "overview of", "public key
calculation")))((("generator point")))The public key is calculated from
the private key using elliptic curve multiplication, which is
irreversible: _K_ = _k_ * _G_, where _k_ is the private key, _G_ is a
constant point called the _generator point_, and _K_ is the resulting
public key. The reverse operation, known as "finding the discrete
logarithm"—calculating _k_ if you know __K__—is as difficult as trying
all possible values of _k_, i.e., a brute-force search. Before we
demonstrate how to generate a public key from a private key, let's look
at elliptic curve cryptography in a bit more detail.

[TIP]
====
Elliptic curve multiplication is a type of function that cryptographers
call a "trap door" function: it is easy to do in one direction
(multiplication) and impossible to do in the reverse direction
(division). The owner of the private key can easily create the public
key and then share it with the world knowing that no one can reverse the
function and calculate the private key from the public key. This
mathematical trick becomes the basis for unforgeable and secure digital
signatures that prove ownership of bitcoin funds.
====

[[elliptic_curve]]
==== Elliptic Curve Cryptography Explained

((("keys and addresses", "overview of", "elliptic curve
cryptography")))((("elliptic curve cryptography",
id="eliptic04")))((("cryptography", "elliptic curve cryptography",
id="Celliptic04")))Elliptic curve cryptography is a type of asymmetric
or public key cryptography based on the discrete logarithm problem as
expressed by addition and multiplication on the points of an elliptic
curve.

<<ecc-curve>> is an example of an elliptic curve, similar to that used
by bitcoin.

[[ecc-curve]]
[role="smallerthirty"]
.An elliptic curve
image::images/mbc2_0402.png["ecc-curve"]

Bitcoin uses a specific elliptic curve and set of mathematical
constants, as defined in a standard called +secp256k1+, established by
the National Institute of Standards and Technology (NIST). The
+secp256k1+ curve is defined by the following function, which produces
an elliptic curve:

[latexmath]
++++
\begin{equation}
{y^2 = (x^3 + 7)}~\text{over}~(\mathbb{F}_p)
\end{equation}
++++

or

[latexmath]
++++
\begin{equation}
{y^2 \mod p = (x^3 + 7) \mod p}
\end{equation}
++++

The _mod p_ (modulo prime number p) indicates that this curve is over a
finite field of prime order _p_, also written as latexmath:[\(
\mathbb{F}_p \)], where p = 2^256^ – 2^32^ – 2^9^ – 2^8^ – 2^7^ – 2^6^ –
2^4^ – 1, a very large prime number.

Because this curve is defined over a finite field of prime order instead
of over the real numbers, it looks like a pattern of dots scattered in
two dimensions, which makes it difficult to visualize. However, the math
is identical to that of an elliptic curve over real numbers. As an
example, <<ecc-over-F17-math>> shows the same elliptic curve over a much
smaller finite field of prime order 17, showing a pattern of dots on a
grid. The +secp256k1+ bitcoin elliptic curve can be thought of as a much
more complex pattern of dots on a unfathomably large grid.

[[ecc-over-F17-math]]
[role="smallersixty"]
.Elliptic curve cryptography: visualizing an elliptic curve over F(p), with p=17
image::images/mbc2_0403.png["ecc-over-F17-math"]

So, for example, the following is a point P with coordinates (x,y) that
is a point on the +secp256k1+ curve:

----
P = (55066263022277343669578718895168534326250603453777594175500187360389116729240, 32670510020758816978083085130507043184471273380659243275938904335757337482424)
----

<<example_4_1>> shows how you can check this yourself using Python:

[[example_4_1]]
.Using Python to confirm that this point is on the elliptic curve
====
[source, pycon]
----
Python 3.4.0 (default, Mar 30 2014, 19:23:13)
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.38)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> p = 115792089237316195423570985008687907853269984665640564039457584007908834671663
>>> x = 55066263022277343669578718895168534326250603453777594175500187360389116729240
>>> y = 32670510020758816978083085130507043184471273380659243275938904335757337482424
>>> (x ** 3 + 7 - y**2) % p
0
----
====

In elliptic curve math, there is a point called the "point at infinity,"
which roughly corresponds to the role of zero in addition. On computers,
it's sometimes represented by x = y = 0 (which doesn't satisfy the
elliptic curve equation, but it's an easy separate case that can be
checked).

There is also a pass:[+] operator, called "addition," which has some
properties similar to the traditional addition of real numbers that
gradeschool children learn. Given two points P~1~ and P~2~ on the
elliptic curve, there is a third point P~3~ = P~1~ + P~2~, also on the
elliptic curve.

Geometrically, this third point P~3~ is calculated by drawing a line
between P~1~ and P~2~. This line will intersect the elliptic curve in
exactly one additional place. Call this point P~3~' = (x, y). Then
reflect in the x-axis to get P~3~ = (x, –y).

There are a couple of special cases that explain the need for the "point
at infinity."

If P~1~ and P~2~ are the same point, the line "between" P~1~ and P~2~
should extend to be the tangent on the curve at this point P~1~. This
tangent will intersect the curve in exactly one new point. You can use
techniques from calculus to determine the slope of the tangent line.
These techniques curiously work, even though we are restricting our
interest to points on the curve with two integer coordinates!

In some cases (i.e., if P~1~ and P~2~ have the same x values but
different y values), the tangent line will be exactly vertical, in which
case P3 = "point at infinity."

If P~1~ is the "point at infinity," then P~1~ + P~2~ = P~2~. Similarly,
if P~2~ is the point at infinity, then P~1~ + P~2~ = P~1~. This shows
how the point at infinity plays the role of zero.

It turns out that pass:[+] is associative, which means that (A pass:[+]
B) pass:[+] C = A pass:[+] (B pass:[+] C). That means we can write A
pass:[+] B pass:[+] C without parentheses and without ambiguity.

Now that we have defined addition, we can define multiplication in the
standard way that extends addition. For a point P on the elliptic curve,
if k is a whole number, then kP = P + P + P + ... + P (k times). Note
that k is sometimes confusingly called an "exponent" in this case.((("",
startref="eliptic04")))((("", startref="Celliptic04")))

[[public_key_derivation]]
==== Generating a Public Key

((("keys and addresses", "overview of", "public key
generation")))((("generator point")))Starting with a private key in the
form of a randomly generated number _k_, we multiply it by a
predetermined point on the curve called the _generator point_ _G_ to
produce another point somewhere else on the curve, which is the
corresponding public key _K_. The generator point is specified as part
of the +secp256k1+ standard and is always the same for all keys in
bitcoin:

[latexmath]
++++
\begin{equation}
{K = k * G}
\end{equation}
++++

where _k_ is the private key, _G_ is the generator point, and _K_ is the
resulting public key, a point on the curve. Because the generator point
is always the same for all bitcoin users, a private key _k_ multiplied
with _G_ will always result in the same public key _K_. The relationship
between _k_ and _K_ is fixed, but can only be calculated in one
direction, from _k_ to _K_. That's why a Bitcoin address (derived from
_K_) can be shared with anyone and does not reveal the user's private
key (_k_).

[TIP]
====
A private key can be converted into a public key, but a public key
cannot be converted back into a private key because the math only works
one way.
====

Implementing the elliptic curve multiplication, we take the private key
_k_ generated previously and multiply it with the generator point G to
find the public key _K_:

----
K = 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD * G
----

Public key _K_ is defined as a point +K = (x,y)+:

----
K = (x, y)

where,

x = F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A
y = 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
----

To visualize multiplication of a point with an integer, we will use the
simpler elliptic curve over real numbers&#x2014;remember, the math is
the same. Our goal is to find the multiple _kG_ of the generator point
_G_, which is the same as adding _G_ to itself, _k_ times in a row. In
elliptic curves, adding a point to itself is the equivalent of drawing a
tangent line on the point and finding where it intersects the curve
again, then reflecting that point on the x-axis.

<<ecc_illustrated>> shows the process for deriving _G_, _2G_, _4G_, as a
geometric operation on the curve.

[TIP]
====
((("OpenSSL cryptographic library")))Many Bitcoin implementations use
the https://github.com/bitcoin-core/secp256k1[libsecp256k1 crytographic
library] to do the elliptic curve math.
====

[[ecc_illustrated]]
.Elliptic curve cryptography: visualizing the multiplication of a point G by an integer k on an elliptic curve
image::images/mbc2_0404.png["ecc_illustrated"]

=== Bitcoin Addresses

((("keys and addresses", "bitcoin addresses", id="KAaddress04")))A
Bitcoin address is a string of digits and characters that can be shared
with anyone who wants to send you money. Addresses produced from public
keys consist of a string of numbers and letters, beginning with the
digit "1." Here's an example of a bitcoin address:

----
1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
----

The Bitcoin address is what appears most commonly in a transaction as
the "recipient" of the funds. If we compare a bitcoin transaction to a
paper check, the Bitcoin address is the beneficiary, which is what we
write on the line after "Pay to the order of." On a paper check, that
beneficiary can sometimes be the name of a bank account holder, but can
also include corporations, institutions, or even cash. Because paper
checks do not need to specify an account, but rather use an abstract
name as the recipient of funds, they are very flexible payment
instruments. Bitcoin transactions use a similar abstraction, the Bitcoin
address, to make them very flexible. A Bitcoin address can represent the
owner of a private/public key pair, or it can represent something else,
such as a payment script, as we will see in <<p2sh>>. For now, let's
examine the simple case, a Bitcoin address that represents, and is
derived from, a public key.

((("addresses", "algorithms used to create")))The Bitcoin address is
derived from the public key through the use of one-way cryptographic
hashing. A "hashing algorithm" or simply "hash algorithm" is a one-way
function that produces a fingerprint or "hash" of an arbitrary-sized
input. Cryptographic hash functions are used extensively in bitcoin: in
Bitcoin addresses, in script addresses, and in the mining Proof-of-Work
algorithm. The algorithms used to make a Bitcoin address from a public
key are the Secure Hash Algorithm (SHA) and the RACE Integrity
Primitives Evaluation Message Digest (RIPEMD), specifically SHA256 and
RIPEMD160.

Starting with the public key _K_, we compute the SHA256 hash and then
compute the RIPEMD160 hash of the result, producing a 160-bit (20-byte)
number:

[latexmath]
++++
\begin{equation}
{A = RIPEMD160(SHA256(K))}
\end{equation}
++++

where _K_ is the public key and _A_ is the resulting Bitcoin address.


[TIP]
====
A Bitcoin address is _not_ the same as a public key. Bitcoin addresses
are derived from a public key using a one-way function.
====

Bitcoin addresses are almost always encoded as "Base58Check" (see
<<base58>>), which uses 58 characters (a Base58 number system) and a
checksum to help human readability, avoid ambiguity, and protect against
errors in address transcription and entry. Base58Check is also used in
many other ways in bitcoin, whenever there is a need for a user to read
and correctly transcribe a number, such as a Bitcoin address, a private
key, an encrypted key, or a script hash. In the next section we will
examine the mechanics of Base58Check encoding and decoding and the
resulting representations. <<pubkey_to_address>> illustrates the
conversion of a public key into a Bitcoin address.

[[pubkey_to_address]]
.Public key to Bitcoin address: conversion of a public key into a Bitcoin address
image::images/mbc2_0405.png["pubkey_to_address"]

[[base58]]
==== Base58 and Base58Check Encoding

((("keys and addresses", "Bitcoin addresses", "Base58 and Base58check
encoding")))((("Base58 and Base58check encoding",
id="base5804")))((("addresses", "Base58 and Base58check encoding",
id="Abase5804")))In order to represent long numbers in a compact way,
using fewer symbols, many computer systems use mixed-alphanumeric
representations with a base (or radix) higher than 10. For example,
whereas the traditional decimal system uses the 10 numerals 0 through 9,
the hexadecimal system uses 16, with the letters A through F as the six
additional symbols. A number represented in hexadecimal format is
shorter than the equivalent decimal representation. Even more compact,
Base64 representation uses 26 lowercase letters, 26 capital letters, 10
numerals, and 2 more characters such as &#x201c;`+`&#x201d; and "/" to
transmit binary data over text-based media such as email. Base64 is most
commonly used to add binary attachments to email. Base58 is a text-based
binary-encoding format developed for use in bitcoin and used in many
other cryptocurrencies. It offers a balance between compact
representation, readability, and error detection and prevention. Base58
is a subset of Base64, using upper- and lowercase letters and numbers,
but omitting some characters that are frequently mistaken for one
another and can appear identical when displayed in certain fonts.
Specifically, Base58 is Base64 without the 0 (number zero), O (capital
o), l (lower L), I (capital i), and the symbols &#x201c;`+`&#x201d; and
"/". Or, more simply, it is a set of lowercase and capital letters and
numbers without the four (0, O, l, I) just mentioned. <<base58alphabet>>
shows the full Base58 alphabet.

[[base58alphabet]]
.Bitcoin's Base58 alphabet
====
----
123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz
----
====

To add extra security against typos or transcription errors, Base58Check
is a Base58 encoding format, frequently used in bitcoin, which has a
built-in error-checking code. The checksum is an additional four bytes
added to the end of the data that is being encoded. The checksum is
derived from the hash of the encoded data and can therefore be used to
detect and prevent transcription and typing errors. When presented with
Base58Check code, the decoding software will calculate the checksum of
the data and compare it to the checksum included in the code. If the two
do not match, an error has been introduced and the Base58Check data is
invalid. This prevents a mistyped Bitcoin address from being accepted by
the wallet software as a valid destination, an error that would
otherwise result in loss of funds.

To convert data (a number) into a Base58Check format, we first add a
prefix to the data, called the "version byte," which serves to easily
identify the type of data that is encoded. For example, in the case of a
Bitcoin address the prefix is zero (0x00 in hex), whereas the prefix
used when encoding a private key is 128 (0x80 in hex). A list of common
version prefixes is shown in <<base58check_versions>>.

Next, we compute the "double-SHA" checksum, meaning we apply the SHA256
hash-algorithm twice on the previous result (prefix and data):

----
checksum = SHA256(SHA256(prefix+data))
----

From the resulting 32-byte hash (hash-of-a-hash), we take only the first
four bytes. These four bytes serve as the error-checking code, or
checksum. The checksum is concatenated (appended) to the end.

The result is composed of three items: a prefix, the data, and a
checksum. This result is encoded using the Base58 alphabet described
previously. <<base58check_encoding>> illustrates the Base58Check
encoding process.

[[base58check_encoding]]
.Base58Check encoding: a Base58, versioned, and checksummed format for unambiguously encoding bitcoin data
image::images/mbc2_0406.png["Base58CheckEncoding"]

In bitcoin, most of the data presented to the user is
Base58Check-encoded to make it compact, easy to read, and easy to detect
errors. The version prefix in Base58Check encoding is used to create
easily distinguishable formats, which when encoded in Base58 contain
specific characters at the beginning of the Base58Check-encoded payload.
These characters make it easy for humans to identify the type of data
that is encoded and how to use it. This is what differentiates, for
example, a Base58Check-encoded Bitcoin address that starts with a 1 from
a Base58Check-encoded private key WIF that starts with a 5. Some example
version prefixes and the resulting Base58 characters are shown in
<<base58check_versions>>.

[[base58check_versions]]
.Base58Check version prefix and encoded result examples
[options="header"]
|=======
|Type| Version prefix (hex)| Base58 result prefix
| Bitcoin Address | 0x00 | 1
| Pay-to-Script-Hash Address | 0x05 | 3
| Bitcoin Testnet Address | 0x6F | m or n
| Private Key WIF |  0x80 | 5, K, or L
| BIP-38 Encrypted Private Key | 0x0142 | 6P
| BIP-32 Extended Public Key | 0x0488B21E | xpub
|=======

==== Key Formats

((("keys and addresses", "Bitcoin addresses", "key formats")))Both
private and public keys can be represented in a number of different
formats. These representations all encode the same number, even though
they look different. These formats are primarily used to make it easy
for people to read and transcribe keys without introducing errors.

[[priv_formats]]
===== Private key formats

((("public and private keys", "private key formats")))The private key
can be represented in a number of different formats, all of which
correspond to the same 256-bit number. <<table_4-2>> shows three common
formats used to represent private keys. Different formats are used in
different circumstances. Hexadecimal and raw binary formats are used
internally in software and rarely shown to users. The WIF is used for
import/export of keys between wallets and often used in QR code
(barcode) representations of private keys.

[[table_4-2]]
.Private key representations (encoding formats)
[options="header"]
|=======
|Type|Prefix|Description
| Raw | None | 32 bytes
| Hex | None | 64 hexadecimal digits
| WIF |  5 | Base58Check encoding: Base58 with version prefix of 128- and 32-bit checksum
| WIF-compressed | K or L | As above, with added suffix 0x01 before encoding
|=======

<<table_4-3>> shows the private key generated in these three formats.

[[table_4-3]]
.Example: Same key, different formats
[options="header"]
|=======
|Format | Private key
| Hex | 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|=======

All of these representations are different ways of showing the same
number, the same private key. They look different, but any one format
can easily be converted to any other format. Note that the "raw binary"
is not shown in <<table_4-3>> as any encoding for display here would, by
definition, not be raw binary data.

We use the +wif-to-ec+ command from Bitcoin Explorer (see <<appdx_bx>>)
to show that both WIF keys represent the same private key:

----
$ bx wif-to-ec 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd

$ bx wif-to-ec KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
----

===== Decode from Base58Check

The Bitcoin Explorer commands (see <<appdx_bx>>) make it easy to write
shell scripts and command-line "pipes" that manipulate bitcoin keys,
addresses, and transactions. You can use Bitcoin Explorer to decode the
Base58Check format on the command line.

We use the +base58check-decode+ command to decode the uncompressed key:

----
$ bx base58check-decode 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
wrapper
{
    checksum 4286807748
    payload 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd
    version 128
}
----

The result contains the key as payload, the WIF version prefix 128, and a checksum.

Notice that the "payload" of the compressed key is appended with the
suffix +01+, signalling that the derived public key is to be compressed:

----
$ bx base58check-decode KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
wrapper
{
    checksum 2339607926
    payload 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd01
    version 128
}
----

===== Encode from hex to Base58Check

To encode into Base58Check (the opposite of the previous command), we
use the +base58check-encode+ command from Bitcoin Explorer (see
<<appdx_bx>>) and provide the hex private key, followed by the WIF
version prefix 128:

----
bx base58check-encode 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd --version 128
5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
----

===== Encode from hex (compressed key) to Base58Check

To encode into Base58Check as a "compressed" private key (see
<<comp_priv>>), we append the suffix +01+ to the hex key and then encode
as in the preceding section:

----
$ bx base58check-encode 1e99423a4ed27608a15a2616a2b0e9e52ced330ac530edcc32c8ffc6a526aedd01 --version 128
KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
----

The resulting WIF-compressed format starts with a "K." This denotes that
the private key within has a suffix of "01" and will be used to produce
compressed public keys only (see <<comp_pub>>).

===== Public key formats

((("public and private keys", "public key formats")))Public keys are
also presented in different ways, usually as either _compressed_ or
_uncompressed_ public keys.

As we saw previously, the public key is a point on the elliptic curve
consisting of a pair of coordinates +(x,y)+. It is usually presented
with the prefix +04+ followed by two 256-bit numbers: one for the _x_
coordinate of the point, the other for the _y_ coordinate. The prefix
+04+ is used to distinguish uncompressed public keys from compressed
public keys that begin with a +02+ or a +03+.

Here's the public key generated by the private key we created earlier,
shown as the coordinates +x+ and +y+:

----
x = F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A
y = 07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
----

Here's the same public key shown as a 520-bit number (130 hex digits)
with the prefix +04+ followed by +x+ and then +y+ coordinates, as +04 x
y+:

++++
<pre data-type="programlisting">
K = 04F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A&#x21b5;
07CF33DA18BD734C600B96A72BBC4749D5141C90EC8AC328AE52DDFE2E505BDB
</pre>
++++

[[comp_pub]]
===== Compressed public keys

((("public and private keys", "compressed public keys")))Compressed
public keys were introduced to bitcoin to reduce the size of
transactions and conserve disk space on nodes that store the Bitcoin
blockchain database. Most transactions include the public key, which is
required to validate the owner's credentials and spend the bitcoin. Each
public key requires 520 bits (prefix + x + y), which when multiplied by
several hundred transactions per block, or tens of thousands of
transactions per day, adds a significant amount of data to the
blockchain.

As we saw in the section <<pubkey>>, a public key is a point (x,y) on an
elliptic curve. Because the curve expresses a mathematical function, a
point on the curve represents a solution to the equation and, therefore,
if we know the _x_ coordinate we can calculate the _y_ coordinate by
solving the equation y^2^ mod p = (x^3^ + 7) mod p. That allows us to
store only the _x_ coordinate of the public key point, omitting the _y_
coordinate and reducing the size of the key and the space required to
store it by 256 bits. An almost 50% reduction in size in every
transaction adds up to a lot of data saved over time!

Whereas uncompressed public keys have a prefix of +04+, compressed
public keys start with either a +02+ or a +03+ prefix. Let's look at why
there are two possible prefixes: because the left side of the equation
is __y__^2^, the solution for _y_ is a square root, which can have a
positive or negative value. Visually, this means that the resulting _y_
coordinate can be above or below the x-axis. As you can see from the
graph of the elliptic curve in <<ecc-curve>>, the curve is symmetric,
meaning it is reflected like a mirror by the x-axis. So, while we can
omit the _y_ coordinate we have to store the _sign_ of _y_ (positive or
negative); or in other words, we have to remember if it was above or
below the x-axis because each of those options represents a different
point and a different public key. When calculating the elliptic curve in
binary arithmetic on the finite field of prime order p, the _y_
coordinate is either even or odd, which corresponds to the
positive/negative sign as explained earlier. Therefore, to distinguish
between the two possible values of _y_, we store a compressed public key
with the prefix +02+ if the _y_ is even, and +03+ if it is odd, allowing
the software to correctly deduce the _y_ coordinate from the _x_
coordinate and uncompress the public key to the full coordinates of the
point. Public key compression is illustrated in <<pubkey_compression>>.

Here's the same public key generated previously, shown as a compressed
public key stored in 264 bits (66 hex digits) with the prefix +03+
indicating the _y_ coordinate is odd:

----
K = 03F028892BAD7ED57D2FB57BF33081D5CFCF6F9ED3D3D7F159C2E2FFF579DC341A
----

This compressed public key corresponds to the same private key, meaning
it is generated from the same private key. However, it looks different
from the uncompressed public key. More importantly, if we convert this
compressed public key to a Bitcoin address using the double-hash
function (+RIPEMD160(SHA256(K))+) it will produce a _different_ Bitcoin
address. This can be confusing, because it means that a single private
key can produce a public key expressed in two different formats
(compressed and uncompressed) that produce two different Bitcoin
addresses. However, the private key is identical for both Bitcoin
addresses.

[[pubkey_compression]]
[role="smallerseventy"]
.Public key compression
image::images/mbc2_0407.png["pubkey_compression"]

Compressed public keys are gradually becoming the default across Bitcoin
clients, which is having a significant impact on reducing the size of
transactions and therefore the blockchain. However, not all clients
support compressed public keys yet. Newer clients that support
compressed public keys have to account for transactions from older
clients that do not support compressed public keys. This is especially
important when a wallet application is importing private keys from
another bitcoin wallet application, because the new wallet needs to scan
the blockchain to find transactions corresponding to these imported
keys. Which Bitcoin addresses should the bitcoin wallet scan for? The
Bitcoin addresses produced by uncompressed public keys, or the Bitcoin
addresses produced by compressed public keys? Both are valid Bitcoin
addresses, and can be signed for by the private key, but they are
different addresses!

To resolve this issue, when private keys are exported from a wallet, the
WIF that is used to represent them is implemented differently in newer
bitcoin wallets, to indicate that these private keys have been used to
produce _compressed_ public keys and therefore _compressed_ Bitcoin
addresses. This allows the importing wallet to distinguish between
private keys originating from older or newer wallets and search the
blockchain for transactions with Bitcoin addresses corresponding to the
uncompressed, or the compressed, public keys, respectively. Let's look
at how this works in more detail, in the next section.

[[comp_priv]]
===== Compressed private keys

((("public and private keys", "compressed private keys")))Ironically,
the term "compressed private key" is a misnomer, because when a private
key is exported as WIF-compressed it is actually one byte _longer_ than
an "uncompressed" private key. That is because the private key has an
added one-byte suffix (shown as 01 in hex in <<table_4-4>>), which
signifies that the private key is from a newer wallet and should only be
used to produce compressed public keys. Private keys are not themselves
compressed and cannot be compressed. The term "compressed private key"
really means "private key from which only compressed public keys should
be derived," whereas "uncompressed private key" really means "private
key from which only uncompressed public keys should be derived." You
should only refer to the export format as "WIF-compressed" or "WIF" and
not refer to the private key itself as "compressed" to avoid further
confusion

<<table_4-4>> shows the same key, encoded in WIF and WIF-compressed formats.

[[table_4-4]]
.Example: Same key, different formats
[options="header"]
|=======
|Format | Private key
| Hex | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD
| WIF | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
| Hex-compressed | 1E99423A4ED27608A15A2616A2B0E9E52CED330AC530EDCC32C8FFC6A526AEDD01
| WIF-compressed | KxFC1jmwwCoACiCAWZ3eXa96mBM6tb3TYzGmf6YwgdGWZgawvrtJ
|=======

Notice that the hex-compressed private key format has one extra byte at
the end (01 in hex). While the Base58 encoding version prefix is the
same (0x80) for both WIF and WIF-compressed formats, the addition of one
byte on the end of the number causes the first character of the Base58
encoding to change from a 5 to either a _K_ or _L_. Think of this as the
Base58 equivalent of the decimal encoding difference between the number
100 and the number 99. While 100 is one digit longer than 99, it also
has a prefix of 1 instead of a prefix of 9. As the length changes, it
affects the prefix. In Base58, the prefix 5 changes to a _K_ or _L_ as
the length of the number increases by one byte.

Remember, these formats are _not_ used interchangeably. In a newer
wallet that implements compressed public keys, the private keys will
only ever be exported as WIF-compressed (with a _K_ or _L_ prefix). If
the wallet is an older implementation and does not use compressed public
keys, the private keys will only ever be exported as WIF (with a 5
prefix). The goal here is to signal to the wallet importing these
private keys whether it must search the blockchain for compressed or
uncompressed public keys and addresses.

If a bitcoin wallet is able to implement compressed public keys, it will
use those in all transactions. The private keys in the wallet will be
used to derive the public key points on the curve, which will be
compressed. The compressed public keys will be used to produce Bitcoin
addresses and those will be used in transactions. When exporting private
keys from a new wallet that implements compressed public keys, the WIF
is modified, with the addition of a one-byte suffix +01+ to the private
key. The resulting Base58Check-encoded private key is called a
"compressed WIF" and starts with the letter _K_ or _L_, instead of
starting with "5" as is the case with WIF-encoded (noncompressed) keys
from older wallets.


[TIP]
====
"Compressed private keys" is a misnomer! They are not compressed;
rather, WIF-compressed signifies that the keys should only be used to
derive compressed public keys and their corresponding Bitcoin addresses.
Ironically, a "WIF-compressed" encoded private key is one byte longer
because it has the added +01+ suffix to distinguish it from an
"uncompressed" one.((("", startref="KAaddress04")))
====

=== Implementing Keys and Addresses in Cpass:[++]

Let's look at the complete process of creating a Bitcoin address, from a
private key, to a public key (a point on the elliptic curve), to a
double-hashed address, and finally, the Base58Check encoding. The C++
code in <<addr_example>> shows the complete step-by-step process, from
private key to Base58Check-encoded Bitcoin address. The code example
uses the libbitcoin library introduced in <<alt_libraries>> for some
helper functions.

[[addr_example]]
.Creating a Base58Check-encoded Bitcoin address from a private key
====
[role="c_less_space"]
[source, cpp]
----
include::code/addr.cpp[]
----
====

The code uses a predefined private key to produce the same Bitcoin
address every time it is run, as shown in <<addr_example_run>>.((("",
startref="base5804")))((("", startref="Abase5804")))

[[addr_example_run]]
.Compiling and running the addr code
====
[source,bash]
----
# Compile the addr.cpp code
$ g++ -o addr addr.cpp -std=c++11 $(pkg-config --cflags --libs libbitcoin)
# Run the addr executable
$ ./addr
Public key: 0202a406624211f2abbdc68da3df929f938c3399dd79fac1b51b0e4ad1d26a47aa
Address: 1PRTTaJesdNovgne6Ehcdu1fpEdX7913CK
----
====

[TIP]
====
The code in <<addr_example_run>> produces a Bitcoin address (+1PRTT...+)
from a _compressed_ public key (see <<comp_pub>>). If you used the
uncompressed public key instead, it would produce a different Bitcoin
address (+14K1y...+).
====

=== Implementing Keys and Addresses in Python

((("keys and addresses", "implementing in Python",
id="KApython04")))((("pybitcointools")))The most comprehensive bitcoin
library in Python is
https://github.com/vbuterin/pybitcointools[pybitcointools] by Vitalik
Buterin. In <<key-to-address_script>>, we use the pybitcointools library
(imported as "bitcoin") to generate and display keys and addresses in
various formats.

[[key-to-address_script]]
.Key and address generation and formatting with the pybitcointools library
====
[source,python]
----
include::code/key-to-address-ecc-example.py[]
----
====

<<key-to-address_script_run>> shows  the output from running this code.

[[key-to-address_script_run]]
.Running key-to-address-ecc-example.py
====
++++
<pre data-type="programlisting">
$ python key-to-address-ecc-example.py
Private Key (hex) is:
 3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa6
Private Key (decimal) is:
 26563230048437957592232553826663696440606756685920117476832299673293013768870
Private Key (WIF) is:
 5JG9hT3beGTJuUAmCQEmNaxAuMacCTfXuw1R3FCXig23RQHMr4K
Private Key Compressed (hex) is:
 3aba4162c7251c891207b747840551a71939b0de081f85c4e44cf7c13e41daa601
Private Key (WIF-Compressed) is:
 KyBsPXxTuVD82av65KZkrGrWi5qLMah5SdNq6uftawDbgKa2wv6S
Public Key (x,y) coordinates is:
 (41637322786646325214887832269588396900663353932545912953362782457239403430124L,
 16388935128781238405526710466724741593761085120864331449066658622400339362166L)
Public Key (hex) is:
 045c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec&#x21b5;
243bcefdd4347074d44bd7356d6a53c495737dd96295e2a9374bf5f02ebfc176
Compressed Public Key (hex) is:
 025c0de3b9c8ab18dd04e3511243ec2952002dbfadc864b9628910169d9b9b00ec
Bitcoin Address (b58check) is:
 1thMirt546nngXqyPEz532S8fLwbozud8
Compressed Bitcoin Address (b58check) is:
 14cxpo3MBCYYWCgF74SWTdcmxipnGUsPw3
</pre>
++++
====

<<ec_math>> is another example, using the Python ECDSA library for the
elliptic curve math and without using any specialized bitcoin libraries.

[[ec_math]]
.A script demonstrating elliptic curve math used for bitcoin keys
====
[source, python]
----
include::code/ec-math.py[]
----
====

<<ec_math_run>> shows the output produced by running this script.

[NOTE]
====
<<ec_math>> ((("random numbers", "os.urandom",
see="entropy")))((("entropy", "os.urandom", see="random
numbers")))((("random numbers", "random number
generation")))((("entropy", "random number generation")))uses
+os.urandom+, which reflects a cryptographically secure random number
generator (CSRNG) provided by the underlying operating system. Caution:
Depending on the OS, +os.urandom+ may _not_ be implemented with
sufficient security or seeded properly and may _not_ be appropriate for
generating production-quality bitcoin keys.((("",
startref="KApython04")))
====

[[ec_math_run]]
.Installing the Python ECDSA library and running the ec_math.py script
====
----
$ # Install Python PIP package manager
$ sudo apt-get install python-pip
$ # Install the Python ECDSA library
$ sudo pip install ecdsa
$ # Run the script
$ python ec-math.py
Secret:  38090835015954358862481132628887443905906204995912378278060168703580660294000
EC point: (70048853531867179489857750497606966272382583471322935454624595540007269312627, 105262206478686743191060800263479589329920209527285803935736021686045542353380)
BTC public key: 029ade3effb0a67d5c8609850d797366af428f4a0d5194cb221d807770a1522873
----
====

=== Advanced Keys and Addresses

((("keys and addresses", "advanced forms", id="KAadvanced04")))In the
following sections we will look at advanced forms of keys and addresses,
such as encrypted private keys, script and multisignature addresses,
vanity addresses, and paper wallets.

==== Encrypted Private Keys (BIP-38)

((("bitcoin improvement proposals", "Encrypted Private Keys
(BIP-38)")))((("keys and addresses", "advanced forms", "encrypted
private keys")))((("public and private keys", "encrypted private
keys")))((("passwords", "encrypted private keys")))((("security",
"passwords")))Private keys must remain secret. The need for
_confidentiality_ of the private keys is a truism that is quite
difficult to achieve in practice, because it conflicts with the equally
important security objective of _availability_. Keeping the private key
private is much harder when you need to store backups of the private key
to avoid losing it. A private key stored in a wallet that is encrypted
by a password might be secure, but that wallet needs to be backed up. At
times, users need to move keys from one wallet to another—to upgrade or
replace the wallet software, for example. Private key backups might also
be stored on paper (see <<paper_wallets>>) or on external storage media,
such as a USB flash drive. But what if the backup itself is stolen or
lost? These conflicting security goals led to the introduction of a
portable and convenient standard for encrypting private keys in a way
that can be understood by many different wallets and bitcoin clients,
standardized by BIP-38 (see <<appdxbitcoinimpproposals>>).

BIP-38 proposes a common standard for encrypting private keys with a
passphrase and encoding them with Base58Check so that they can be stored
securely on backup media, transported securely between wallets, or kept
in any other conditions where the key might be exposed. The standard for
encryption uses the Advanced Encryption Standard (AES), a standard
established by the NIST and used broadly in data encryption
implementations for commercial and military applications.

A BIP-38 encryption scheme takes as input a bitcoin private key, usually
encoded in the WIF, as a Base58Check string with the prefix of "5."
Additionally, the BIP-38 encryption scheme takes a passphrase—a long
password—usually composed of several words or a complex string of
alphanumeric characters. The result of the BIP-38 encryption scheme is a
Base58Check-encoded encrypted private key that begins with the prefix
+6P+. If you see a key that starts with +6P+, it is encrypted and
requires a passphrase in order to convert (decrypt) it back into a
WIF-formatted private key (prefix +5+) that can be used in any wallet.
Many wallet applications now recognize BIP-38-encrypted private keys and
will prompt the user for a passphrase to decrypt and import the key.
Third-party applications, such as the incredibly useful browser-based
http://bitaddress.org[Bit Address] (Wallet Details tab), can be used to
decrypt BIP-38 keys.

The most common use case for BIP-38 encrypted keys is for paper wallets
that can be used to back up private keys on a piece of paper. As long as
the user selects a strong passphrase, a paper wallet with BIP-38
encrypted private keys is incredibly secure and a great way to create
offline bitcoin storage (also known as "cold storage").

Test the encrypted keys in <<table_4-10>> using bitaddress.org to see
how you can get the decrypted key by entering the passphrase.

[[table_4-10]]
.Example of BIP-38 encrypted private key
|=======
| *Private Key (WIF)* | 5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
| *Passphrase* | MyTestPassphrase
| *Encrypted Key (BIP-38)* | 6PRTHL6mWa48xSopbU1cKrVjpKbBZxcLRRCdctLJ3z5yxE87MobKoXdTsJ
|=======

[[p2sh_addresses]]
==== Pay-to-Script Hash (P2SH) and Multisig Addresses

((("keys and addresses", "advanced forms", "pay-to-script hash and
multisig addresses")))((("Pay-to-Script-Hash (P2SH)", "multisig
addresses and")))((("multisig addresses")))((("addresses", "multisig
addresses")))As we know, traditional Bitcoin addresses begin with the
number “1” and are derived from the public key, which is derived from
the private key.  Although anyone can send bitcoin to a “1” address,
that bitcoin can only be spent by presenting the corresponding private
key signature and public key hash.

((("bitcoin improvement proposals", "Pay to Script Hash
(BIP-16)")))Bitcoin addresses that begin with the number “3” are
pay-to-script hash (P2SH) addresses, sometimes erroneously called
multisignature or multisig addresses. They designate the beneficiary of
a Bitcoin transaction as the hash of a script, instead of the owner of a
public key. The feature was introduced in January 2012 with BIP-16 (see
<<appdxbitcoinimpproposals>>), and is being widely adopted because it
provides the opportunity to add functionality to the address itself.
Unlike transactions that "send" funds to traditional “1” Bitcoin
addresses, also known as a pay-to-public-key-hash (P2PKH), funds sent to
“3” addresses require something more than the presentation of one public
key hash and one private key signature as proof of ownership. The
requirements are designated at the time the address is created, within
the script, and all inputs to this address will be encumbered with the
same requirements.

A P2SH address is created from a transaction script, which defines who
can spend a transaction output (for more details, see <<p2sh>>).
Encoding a P2SH address involves using the same double-hash function as
used during creation of a Bitcoin address, only applied on the script
instead of the public key:

----
script hash = RIPEMD160(SHA256(script))
----

The resulting "script hash" is encoded with Base58Check with a version
prefix of 5, which results in an encoded address starting with a +3+. An
example of a P2SH address is +3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM+, which
can be derived using the Bitcoin Explorer commands +script-encode+,
+sha256+, +ripemd160+, and +base58check-encode+ (see <<appdx_bx>>) as
follows:

----
$ echo \
'DUP HASH160 [89abcdefabbaabbaabbaabbaabbaabbaabbaabba] EQUALVERIFY CHECKSIG' > script
$ bx script-encode < script | bx sha256 | bx ripemd160 \
| bx base58check-encode --version 5
3F6i6kwkevjR7AsAd4te2YB2zZyASEm1HM
----

[TIP]
====
P2SH is not necessarily the same as a multisignature standard
transaction. A P2SH address _most often_ represents a multi-signature
script, but it might also represent a script encoding other types of
transactions.
====

===== Multisignature addresses and P2SH

Currently, the most common implementation of the P2SH function is the
multi-signature address script. As the name implies, the underlying
script requires more than one signature to prove ownership and therefore
spend funds. The bitcoin multi-signature feature is designed to require
M signatures (also known as the “threshold”) from a total of N keys,
known as an M-of-N multisig, where M is equal to or less than N. For
example, Bob the coffee shop owner from <<ch01_intro_what_is_bitcoin>>
could use a multisignature address requiring 1-of-2 signatures from a
key belonging to him and a key belonging to his spouse, ensuring either
of them could sign to spend a transaction output locked to this address.
This would be similar to a “joint account” as implemented in traditional
banking where either spouse can spend with a single signature. Or
Gopesh,((("use cases", "offshore contract services"))) the web designer
paid by Bob to create a website, might have a 2-of-3 multisignature
address for his business that ensures that no funds can be spent unless
at least two of the business partners sign a transaction.

We will explore how to create transactions that spend funds from P2SH
(and multi-signature) addresses in <<transactions>>.

==== Vanity Addresses

((("keys and addresses", "advanced forms", "vanity
addresses")))((("vanity addresses", id="vanity04")))((("addresses",
"vanity addresses", id="Avanity04")))Vanity addresses are valid Bitcoin
addresses that contain human-readable messages. For example,
+1LoveBPzzD72PUXLzCkYAtGFYmK5vYNR33+ is a valid address that contains
the letters forming the word "Love" as the first four Base-58 letters.
Vanity addresses require generating and testing billions of candidate
private keys, until a bitcoin address with the desired pattern is found.
Although there are some optimizations in the vanity generation
algorithm, the process essentially involves picking a private key at
random, deriving the public key, deriving the Bitcoin address, and
checking to see if it matches the desired vanity pattern, repeating
billions of times until a match is found.

Once a vanity address matching the desired pattern is found, the private
key from which it was derived can be used by the owner to spend bitcoin
in exactly the same way as any other address. Vanity addresses are no
less or more secure than any other address. They depend on the same
Elliptic Curve Cryptography (ECC) and SHA as any other address. You can
no more easily find the private key of an address starting with a vanity
pattern than you can any other address.

In <<ch01_intro_what_is_bitcoin>>, we introduced Eugenia, a children's
charity director operating in the Philippines. Let's say that Eugenia is
organizing a bitcoin fundraising drive and wants to use a vanity Bitcoin
address to publicize the fundraising. Eugenia will create a vanity
address that starts with "1Kids" to promote the children's charity
fundraiser. Let's see how this vanity address will be created and what
it means for the security of Eugenia's charity.((("use cases",
"charitable donations", startref="eugeniafour")))

===== Generating vanity addresses

It's important to realize that a Bitcoin address is simply a number
represented by symbols in the Base58 alphabet. The search for a pattern
like "1Kids" can be seen as searching for an address in the range from
+1Kids11111111111111111111111111111+ to
+1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+. There are approximately 58^29^
(approximately 1.4 * 10^51^) addresses in that range, all starting with
"1Kids." <<table_4-11>> shows the range of addresses that have the
prefix 1Kids.

[[table_4-11]]
.The range of vanity addresses starting with "1Kids"
|=======
| *From* | +1Kids11111111111111111111111111111+
| | +1Kids11111111111111111111111111112+
| | +1Kids11111111111111111111111111113+
| | +...+
| *To* | +1Kidszzzzzzzzzzzzzzzzzzzzzzzzzzzzz+
|=======

Let's look at the pattern "1Kids" as a number and see how frequently we
might find this pattern in a Bitcoin address (see <<table_4-12>>). An
average desktop computer PC, without any specialized hardware, can
search approximately 100,000 keys per second.

[[table_4-12]]
.The frequency of a vanity pattern (1KidsCharity) and average search time on a desktop PC
[options="header"]
|=======
| Length | Pattern | Frequency | Average search time
| 1 | 1K | 1 in 58 keys | < 1 milliseconds
| 2 | 1Ki| 1 in 3,364 | 50 milliseconds
| 3 | 1Kid | 1 in 195,000 | < 2 seconds
| 4 | 1Kids | 1 in 11 million | 1 minute
| 5 | 1KidsC | 1 in 656 million | 1 hour
| 6 | 1KidsCh | 1 in 38 billion | 2 days
| 7 | 1KidsCha | 1 in 2.2 trillion | 3–4 months
| 8 | 1KidsChar | 1 in 128 trillion | 13–18 years
| 9 | 1KidsChari | 1 in 7 quadrillion | 800 years
| 10 | 1KidsCharit | 1 in 400 quadrillion | 46,000 years
| 11 | 1KidsCharity | 1 in 23 quintillion | 2.5 million years
|=======

As you can see, Eugenia won't be creating the vanity address
"1KidsCharity" anytime soon, even if she had access to several thousand
computers. Each additional character increases the difficulty by a
factor of 58. Patterns with more than seven characters are usually found
by specialized hardware, such as custom-built desktops with multiple
GPUs. These are often repurposed bitcoin mining "rigs" that are no
longer profitable for bitcoin mining but can be used to find vanity
addresses. Vanity searches on GPU systems are many orders of magnitude
faster than on a general-purpose CPU.

Another way to find a vanity address is to outsource the work to a pool
of vanity miners, such as the pool at
http://vanitypool.appspot.com[Vanity Pool]. A pool is a service that
allows those with GPU hardware to earn bitcoin searching for vanity
addresses for others. For a small payment (0.01 bitcoin or approximately
$5 at the time of this writing), Eugenia can outsource the search for a
seven-character pattern vanity address and get results in a few hours
instead of having to run a CPU search for months.

Generating a vanity address is a brute-force exercise: try a random key,
check the resulting address to see if it matches the desired pattern,
repeat until successful. <<vanity_miner_code>> shows an example of a
"vanity miner," a program designed to find vanity addresses, written in
C++. The example uses the libbitcoin library, which we introduced in
<<alt_libraries>>.

[[vanity_miner_code]]
.Vanity address miner
====
[source,cpp]
----
include::code/vanity-miner.cpp[]
----
====

[NOTE]
====
<<vanity_miner_run>> uses +std::random_device+. Depending on the
implementation it may reflect a CSRNG provided by the underlying
operating system. In the case of a Unix-like operating system such as
Linux, it draws from +/dev/urandom+. The random number generator used
here is for demonstration purposes, and it is _not_ appropriate for
generating production-quality bitcoin keys as it is not implemented with
sufficient security.
====

The example code must be compiled using a pass:[C++] compiler and linked
against the libbitcoin library (which must be first installed on that
system). To run the example, run the ++vanity-miner++ executable with no
parameters (see <<vanity_miner_run>>) and it will attempt to find a
vanity address starting with "1kid."

[[vanity_miner_run]]
.Compiling and running the vanity-miner example
====
[source,bash]
----
$ # Compile the code with g++
$ g++ -o vanity-miner vanity-miner.cpp $(pkg-config --cflags --libs libbitcoin)
$ # Run the example
$ ./vanity-miner
Found vanity address! 1KiDzkG4MxmovZryZRj8tK81oQRhbZ46YT
Secret: 57cc268a05f83a23ac9d930bc8565bac4e277055f4794cbd1a39e5e71c038f3f
$ # Run it again for a different result
$ ./vanity-miner
Found vanity address! 1Kidxr3wsmMzzouwXibKfwTYs5Pau8TUFn
Secret: 7f65bbbbe6d8caae74a0c6a0d2d7b5c6663d71b60337299a1a2cf34c04b2a623
# Use "time" to see how long it takes to find a result
$ time ./vanity-miner
Found vanity address! 1KidPWhKgGRQWD5PP5TAnGfDyfWp5yceXM
Secret: 2a802e7a53d8aa237cd059377b616d2bfcfa4b0140bc85fa008f2d3d4b225349

real	0m8.868s
user	0m8.828s
sys	0m0.035s
----
====

The example code will take a few seconds to find a match for the
three-character pattern "kid," as we can see when we use the +time+ Unix
command to measure the execution time. Change the +search+ pattern in
the source code and see how much longer it takes for four- or
five-character patterns!

===== Vanity address security

((("security", "vanity addresses")))Vanity addresses can be used to
enhance _and_ to defeat security measures; they are truly a double-edged
sword. Used to improve security, a distinctive address makes it harder
for adversaries to substitute their own address and fool your customers
into paying them instead of you. Unfortunately, vanity addresses also
make it possible for anyone to create an address that _resembles_ any
random address, or even another vanity address, thereby fooling your
customers.

Eugenia could advertise a randomly generated address (e.g.,
+1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy+) to which people can send their
donations. Or, she could generate a vanity address that starts with
1Kids, to make it more distinctive.

In both cases, one of the risks of using a single fixed address (rather
than a separate dynamic address per donor) is that a thief might be able
to infiltrate your website and replace it with his own address, thereby
diverting donations to himself. If you have advertised your donation
address in a number of different places, your users may visually inspect
the address before making a payment to ensure it is the same one they
saw on your website, on your email, and on your flyer. In the case of a
random address like +1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy+, the average
user will perhaps inspect the first few characters "1J7mdg" and be
satisfied that the address matches. Using a vanity address generator,
someone with the intent to steal by substituting a similar-looking
address can quickly generate addresses that match the first few
characters, as shown in <<table_4-13>>.

[[table_4-13]]
.Generating vanity addresses to match a random address
|=======
| *Original Random Address* | 1J7mdg5rbQyUHENYdx39WVWK7fsLpEoXZy
| *Vanity (4-character match)* | 1J7md1QqU4LpctBetHS2ZoyLV5d6dShhEy
| *Vanity (5-character match)* | 1J7mdgYqyNd4ya3UEcq31Q7sqRMXw2XZ6n
| *Vanity (6-character match)* | 1J7mdg5WxGENmwyJP9xuGhG5KRzu99BBCX
|=======

So does a vanity address increase security? If Eugenia generates the
vanity address +1Kids33q44erFfpeXrmDSz7zEqG2FesZEN+, users are likely to
look at the vanity pattern word _and a few characters beyond_, for
example noticing the "1Kids33" part of the address. That would force an
attacker to generate a vanity address matching at least six characters
(two more), expending an effort that is 3,364 times (58 &#x00D7; 58)
higher than the effort Eugenia expended for her 4-character vanity.
Essentially, the effort Eugenia expends (or pays a vanity pool for)
"pushes" the attacker into having to produce a longer pattern vanity. If
Eugenia pays a pool to generate an 8-character vanity address, the
attacker would be pushed into the realm of 10 characters, which is
infeasible on a personal computer and expensive even with a custom
vanity-mining rig or vanity pool. What is affordable for Eugenia becomes
unaffordable for the attacker, especially if the potential reward of
fraud is not high enough to cover the cost of the vanity address
generation.((("", startref="Avanity04")))((("",
startref="vanity04")))((("", startref="eugeniafour")))

[[paper_wallets]]
==== Paper Wallets

((("keys and addresses", "advanced forms", "paper wallets")))((("paper
wallets", id="paperw04")))((("wallets", "types of", "paper wallets",
id="Wpaper04")))Paper wallets are bitcoin private keys printed on paper.
Often the paper wallet also includes the corresponding Bitcoin address
for convenience, but this is not necessary because it can be derived
from the private key.

[WARNING]
====
Paper wallets are an OBSOLETE technology and are dangerous for most
users. There are many subtle pitfalls involved in generating them, not
least of which the possibility that the generating code is compromised
with a "back door". Hundreds of bitcoin have been stolen this way. Paper
wallets are shown here for informational purposes only and should not be
used for storing bitcoin. Use a BIP-39 mnemonic phrase to backup your
keys. Use a hardware wallet to store keys and sign transactions. DO NOT
USE PAPER WALLETS.
====

Paper wallets come in many shapes, sizes, and designs, but at a very
basic level are just a key and an address printed on paper.
<<table_4-14>> shows the simplest form of a paper wallet.

[[table_4-14]]
.Simplest form of a paper wallet—a printout of the Bitcoin address and private key
[options="header"]
|=======================
|Public address|Private key (WIF)
|1424C2F4bC9JidNjjTUZCbUxv6Sa1Mt62x|5J3mBbAH58CpQ3Y5RNJpUKPE62SQ5tfcvU2JpbnkeyhfsYB1Jcn
|=======================

Paper wallets come in many designs and sizes, with many different
features. <<paper_wallet_simple>> shows a sample paper wallet.

[[paper_wallet_simple]]
.An example of a simple paper wallet
image::images/mbc2_0408.png[]

Some are intended to be given as gifts and have seasonal themes, such as
Christmas and New Year's themes. Others are designed for storage in a
bank vault or safe with the private key hidden in some way, either with
opaque scratch-off stickers, or folded and sealed with tamper-proof
adhesive foil.  Other designs feature additional copies of the key and
address, in the form of detachable stubs similar to ticket stubs,
allowing you to store multiple copies to protect against fire, flood, or
other natural disasters.((("", startref="KAadvanced04")))((("",
startref="Wpaper04")))((("", startref="paperw04")))

[[paper_wallet_spw]]
.An example of a paper wallet with additional copies of the keys on a backup "stub"
image::images/mbc2_0412.png[]