DUST ATTACK

A Bitcoin invoice address, or simply invoice, is an identifier of 26-35 alphanumeric characters, beginning with the number 1, 3 or bc1 that represents a possible destination for a bitcoin payment. Invoices can be generated at no cost by any user of Bitcoin. It is also possible to get a Bitcoin invoice address using an account at an exchange or online wallet service.

There are currently three invoice address formats in use:

1. P2PKH which begin with the number 1, eg: 1BvBMSEYstWetqTFn5Au4m4GFg7xJaNVN2.
2. P2SH type starting with the number 3, eg: 3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy.
3. Bech32 type starting with bc1, eg: bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq.

A Bitcoin invoice address is a single-use token

Like e-mail addresses, you can send bitcoins to a person by sending bitcoins to one of their invoice addresses. However, unlike e-mail addresses, people have many different Bitcoin invoice addresses and for privacy and security reasons a unique invoice should be used for each transaction. Most Bitcoin software and websites will help with this by generating a brand new invoice each time you create an invoice or payment request.

A naive way to accept bitcoin as a merchant is to tell your customers to send money to a single invoice address. However this does not work because Bitcoin transactions are public on the block chain, so if a customer Alice sends you bitcoins then a malicious agent Bob could see that same transaction and send you an email claiming that he paid. You would have no way of knowing whether it was Alice or Bob who send coins to your invoice. This is why each customer must be given a brand new invoice.

Invoices can be created offline

Creating invoices can be done without an Internet connection and does not require any contact or registration with the Bitcoin network. It is possible to create large batches of invoices offline using freely available software tools. Generating batches of invoices is useful in several scenarios, such as e-commerce websites where a unique pre-generated invoice address is dispensed to each customer who chooses a “pay with Bitcoin” option. Newer “HD wallets” can generate a “master public key” token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of invoices without the ability to spend the bitcoins received.

Invoice addresses are often case sensitive and exact

Old-style Bitcoin invoice addresses are case-sensitive. Bitcoin invoices should be copied and pasted using the computer’s clipboard wherever possible. If you hand-key a Bitcoin invoice address, and each character is not transcribed exactly – including capitalization – the incorrect invoice address will most likely be rejected by the Bitcoin software. You will have to check your entry and try again.

The probability that a mistyped invoice is accepted as being valid is 1 in 2³², that is, approximately 1 in 4.29 billion.

New-style bech32 invoices are case insensitive.

Proving you receive with an invoice address

Most Bitcoin wallets have a function to “sign” a message, proving the entity receiving funds with an invoice has agreed to the message. This can be used to, for example, finalise a contract in a cryptographically provable way prior to making payment for it.

Some services will also piggy-back on this capability by dedicating a specific invoice address for authentication only, in which case the invoice address should never be used for actual Bitcoin transactions. When you login to or use their service, you will provide a signature proving you are the same person with the pre-negotiated invoice address.

It is important to note that these signatures only prove one receives with an invoice. Since Bitcoin transactions do not have a “from” address, you cannot prove you are the sender of funds.

Current standards for message signatures are only compatible with “version zero” bitcoin invoice addresses (that begin with the number 1).

Invoice address validation

If you would like to validate a Bitcoin invoice address in an application, it is advisable to use a method from this thread rather than to just check for string length, allowed characters, or that the invoice starts with a 1 or 3. Validation may also be done using open source code available in various languages or with an online validating tool.

Multi-signature invoice addresses

Invoices can be created for keys that require a combination of multiple private keys. Since these take advantage of newer features, they begin with the newer prefix of 3 or bc1 instead of the older 1. These can be thought of as the equivalent of writing a check to two parties – “pay to the order of somebody AND somebody else” – where both parties must endorse the check in order to receive the funds.

The actual requirement (number of private keys needed, their corresponding public keys, etc.) that must be satisfied to spend the funds is decided in advance by the person generating this type of invoice, and once an invoice is created, the requirement cannot be changed without generating a new invoice.

What’s in an invoice

Most Bitcoin invoice addresses are 34 characters. They consist of random digits and uppercase and lowercase letters, with the exception that the uppercase letter “O”, uppercase letter “I”, lowercase letter “l”, and the number “0” are never used to prevent visual ambiguity.

Some Bitcoin invoice addresses can be shorter than 34 characters (as few as 26) and still be valid. A significant percentage of Bitcoin invoice addresses are only 33 characters, and some invoices may be even shorter. Technically, every Bitcoin invoice stands for a number. These shorter invoices are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded invoice address gets shorter.

Several of the characters inside a Bitcoin invoice are used as a checksum so that typographical errors can be automatically found and rejected. The checksum also allows Bitcoin software to confirm that a 33-character (or shorter) invoice is in fact valid and isn’t simply an invoice with a missing character.

Testnet

Invoice addresses on the Bitcoin Testnet are generated with a different prefix. See List of address prefixes and Testnet for more details.

Misconceptions

Address reuse

Invoice addresses are not intended to be used more than once, and doing so has numerous problems associated. See the dedicated article on address reuse for more details.

Address balances

Invoice addresses are not wallets nor accounts, and do not carry balances. They only receive funds, and you do not send “from” an address at any time. Various confusing services and software display bitcoins received with an invoice address, minus bitcoins sent in random unrelated transactions as an “address balance”, but this number is not meaningful: it does not imply the recipient of the bitcoins sent to the address has spent them, nor that they still have or don’t have the bitcoins received.

An example of bitcoin loss resulting from this misunderstanding is when people believed their invoice address contained 3 BTC. They spent 0.5 BTC and believed the address now contained 2.5 BTC when actually it contained zero. The remaining 2.5 BTC was transferred to a “change address” which was not backed up and therefore lost. This has happened on a few occasions to users of Paper wallets.

“From” addresses

Bitcoin transactions do not have any kind of origin-, source- or “from” address. See the dedicated article on “from address” for more details.

Address map

Technical background of version 1 Bitcoin addresses

This article may be too technical for some users. The more basic article on Bitcoin Addresses may be more appropriate.

A Bitcoin address is a 160-bit hash of the public portion of a public/private ECDSA keypair. Using public-key cryptography, you can “sign” data with your private key and anyone who knows your public key can verify that the signature is valid.

A new keypair is generated for each receiving address (with newer HD wallets, this is done deterministically). The public key and their associated private keys (or the seed needed to generate them) are stored in the wallet data file. This is the only file users should need to backup. A “send” transaction to a specific Bitcoin address requires that the corresponding wallet knows the private key implementing it. This has the implication that if you create an address and receive coins to that address, then restore the wallet from an earlier backup, before the address was generated, then the coins received with that address are lost; this is not an issue for HD wallets where all addresses are generated from a single seed. Addresses are added to an address key pool prior to being used for receiving coins. If you lose your wallet entirely, all of your coins are lost and can never be recovered.

Bitcoin allows you to create as many addresses as you want, and use a new one for every transaction. There is no “master address”: the “Your Bitcoin address” area in some wallet UIs has no special importance. It’s only there for your convenience, and it should change automatically when used.

Bitcoin addresses contain a built-in check code, so it’s generally not possible to send Bitcoins to a mistyped address. However, if the address is well-formed but no one owns it (or the owner lost their wallet.dat), any coins sent to that address will be lost forever.

Hash values and the checksum data are converted to an alpha-numeric representation using a custom scheme: the Base58Check encoding scheme. Under Base58Check, addresses can contain all alphanumeric characters except 0, O, I, and l. Mainnet P2PKH addresses start with 1, while P2SH addresses start with 3 (Bech32 addresses start with bc1 and do not use Base58Check encoding). Testnet addresses usually start with m or n. Mainnet addresses can be 25-34 characters in length, and testnet addresses can be 26-34 characters in length. Most addresses are 33 or 34 characters long.

Collisions (lack thereof)

Since Bitcoin addresses are basically random numbers, it is possible, although extremely unlikely, for two people to independently generate the same address. This is called a collision. If this happens, then both the original owner of the address and the colliding owner could spend money sent to that address. It would not be possible for the colliding person to spend the original owner’s entire wallet (or vice versa).

But because the space of possible addresses is so astronomically large it is more likely that the Earth is destroyed in the next 5 seconds, than that a collision occur in the next millenium.

How to create Bitcoin Address

The correct way to create a Bitcoin address is to use well tested, open source, peer reviewed wallet software. Manually handling keys has resulted in funds loss over and over again. Unlike other centralized systems losses in Bitcoin are usually unrecoverable.

Here is a brief overview of how address generation works, for informational purposes:

0 – Having a private ECDSA key 18e14a7b6a307f426a94f8114701e7c8e774e7f9a47e2c2035db29a206321725

1 – Take the corresponding public key generated with it (33 bytes, 1 byte 0x02 (y-coord is even), and 32 bytes corresponding to X coordinate) 0250863ad64a87ae8a2fe83c1af1a8403cb53f53e486d8511dad8a04887e5b2352

2 – Perform SHA-256 hashing on the public key 0b7c28c9b7290c98d7438e70b3d3f7c848fbd7d1dc194ff83f4f7cc9b1378e98

3 – Perform RIPEMD-160 hashing on the result of SHA-256 f54a5851e9372b87810a8e60cdd2e7cfd80b6e31

4 – Add version byte in front of RIPEMD-160 hash (0x00 for Main Network) 00f54a5851e9372b87810a8e60cdd2e7cfd80b6e31

(note that below steps are the Base58Check encoding, which has multiple library options available implementing it)
5 – Perform SHA-256 hash on the extended RIPEMD-160 result ad3c854da227c7e99c4abfad4ea41d71311160df2e415e713318c70d67c6b41c

6 – Perform SHA-256 hash on the result of the previous SHA-256 hash c7f18fe8fcbed6396741e58ad259b5cb16b7fd7f041904147ba1dcffabf747fd

7 – Take the first 4 bytes of the second SHA-256 hash. This is the address checksum c7f18fe8

8 – Add the 4 checksum bytes from stage 7 at the end of extended RIPEMD-160 hash from stage 4. This is the 25-byte binary Bitcoin Address. 00f54a5851e9372b87810a8e60cdd2e7cfd80b6e31c7f18fe8

9 – Convert the result from a byte string into a base58 string using Base58Check encoding. This is the most commonly used Bitcoin Address format 1PMycacnJaSqwwJqjawXBErnLsZ7RkXUAs

Exit Address

Exit addresses (first described here) are defined as follows: “When you create an account with a site, you should be able to enter an address that, should anything go wrong, your coins will be sent to. Deepbit, for example has an option that will let you ‘lock your payments address forever’ meaning, even if someone hijacks your account, they won’t be able to withdraw money anywhere.”

Many members of the bitcoin community have advocated that any service accepting bitcoin deposits (as opposed to payments — i.e. exchanges, etc) ought to include an exit address facility, and allow enactment of exit address policy at any time. This would avoid the conflict of interest inherent in “anti-money-laundering” account freezures, whereby the exchange actually books a profit under accepted accounting practices as a result of balances inheriting from accounts abandoned in response to account freezure (once the statue of limitations on embezzlement expires).

Blockchain-based currencies use encoded strings, which are in a Base58Check encoding with the exception of Bech32 encodings. The encoding includes a prefix (traditionally a single version byte), which affects the leading symbol(s) in the encoded result. The following is a list of some prefixes which are in use in the reference Bitcoin codebase.^[1][2][3]

Decimal prefix	Hex	Example use	Leading symbol(s)	Example
0	00	Pubkey hash (P2PKH address)	1	17VZNX1SN5NtKa8UQFxwQbFeFc3iqRYhem
5	05	Script hash (P2SH address)	3	3EktnHQD7RiAE6uzMj2ZifT9YgRrkSgzQX
128	80	Private key (WIF, uncompressed pubkey)	5	5Hwgr3u458GLafKBgxtssHSPqJnYoGrSzgQsPwLFhLNYskDPyyA
133	80	Private key (WIF, uncompressed pubkey, Electrum-defined[4] and now deprecated[5])	5	5TfQjD9DLFeUFmDiDrzsdtSGQss93o4pvsmQcgmjfcQVLsEgAoM
128	80	Private key (WIF, compressed pubkey)	K or L	L1aW4aubDFB7yfras2S1mN3bqg9nwySY8nkoLmJebSLD5BWv3ENZ
129-134	80	Private key (WIF, compressed pubkey, Electrum-defined[4] and now deprecated[5])	L	LkUevPi661korFvRdQQUkEX35rA484oAwzsT93383q6mUqVe5cw2
135	80	Private key (WIF, compressed pubkey, Electrum-defined[4] and now deprecated[5])	L or M	M3dv4iRtSKb5oHwxjZCGLai1aiZMnuLdGt7iFwjK2ncC3Vu7tRwP
4 136 178 30	0488B21E	BIP32 pubkey	xpub	xpub661MyMwAqRbcEYS8w7XLSVeEsBXy79zSzH1J8vCdxAZningWLdN3zgtU6LBpB85b3D2yc8sfvZU521AAwdZafEz7mnzBBsz4wKY5e4cp9LB
4 136 173 228	0488ADE4	BIP32 private key	xprv	xprv9s21ZrQH143K24Mfq5zL5MhWK9hUhhGbd45hLXo2Pq2oqzMMo63oStZzF93Y5wvzdUayhgkkFoicQZcP3y52uPPxFnfoLZB21Teqt1VvEHx
111	6F	Testnet pubkey hash	m or n	mipcBbFg9gMiCh81Kj8tqqdgoZub1ZJRfn
196	C4	Testnet script hash	2	2MzQwSSnBHWHqSAqtTVQ6v47XtaisrJa1Vc
239	EF	Testnet Private key (WIF, uncompressed pubkey)	9	92Pg46rUhgTT7romnV7iGW6W1gbGdeezqdbJCzShkCsYNzyyNcc
239	EF	Testnet Private key (WIF, compressed pubkey)	c	cNJFgo1driFnPcBdBX8BrJrpxchBWXwXCvNH5SoSkdcF6JXXwHMm
4 53 135 207	043587CF	Testnet BIP32 pubkey	tpub	tpubD6NzVbkrYhZ4WLczPJWReQycCJdd6YVWXubbVUFnJ5KgU5MDQrD998ZJLNGbhd2pq7ZtDiPYTfJ7iBenLVQpYgSQqPjUsQeJXH8VQ8xA67D
4 53 131 148	04358394	Testnet BIP32 private key	tprv	tprv8ZgxMBicQKsPcsbCVeqqF1KVdH7gwDJbxbzpCxDUsoXHdb6SnTPYxdwSAKDC6KKJzv7khnNWRAJQsRA8BBQyiSfYnRt6zuu4vZQGKjeW4YF
		Bech32 pubkey hash or script hash	bc1	bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4
		Bech32 testnet pubkey hash or script hash	tb1	tb1qw508d6qejxtdg4y5r3zarvary0c5xw7kxpjzsx

Note that private keys for compressed and uncompressed bitcoin public keys use the same version byte. The reason for the compressed form starting with a different character is because a 0x01 byte is appended to the private key before base58 encoding.

The following table shows the leading symbol(s) and address length(s) for 160 bit hashes for each of the possible decimal version values:

Decimal version	Leading symbol	Address length
0	1	up to 34
1	Q-Z, a-k, m-o	33
2	o-z, 2	33 or 34
3	2	34
4	2 or 3	34
5-6	3	34
7	3 or 4	34
8	4	34
9	4 or 5	34
10-11	5	34
12	5 or 6	34
13	6	34
14	6 or 7	34
15-16	7	34
17	7 or 8	34
18	8	34
19	8 or 9	34
20-21	9	34
22	9 or A	34
23	A	34
24	A or B	34
25-26	B	34
27	B or C	34
28	C	34
29	C or D	34
30-31	D	34
32	D or E	34
33	E	34
34	E or F	34
35-36	F	34
37	F or G	34
38	G	34
39	G or H	34
40-41	H	34
42	H or J	34
43	J	34
44	J or K	34
45-46	K	34
47	K or L	34
48	L	34
49	L or M	34
50-51	M	34
52	M or N	34
53	N	34
54	N or P	34
55-56	P	34
57	P or Q	34
58	Q	34
59	Q or R	34
60-61	R	34
62	R or S	34
63	S	34
64	S or T	34
65-66	T	34
67	T or U	34
68	U	34
69	U or V	34
70-71	V	34
72	V or W	34
73	W	34
74	W or X	34
75-76	X	34
77	X or Y	34
78	Y	34
79	Y or Z	34
80-81	Z	34
82	Z or a	34
83	a	34
84	a or b	34
85	b	34
86	b or c	34
87-88	c	34
89	c or d	34
90	d	34
91	d or e	34
92-93	e	34
94	e or f	34
95	f	34
96	f or g	34
97-98	g	34
99	g or h	34
100	h	34
101	h or i	34
102-103	i	34
104	i or j	34
105	j	34
106	j or k	34
107-108	k	34
109	k or m	34
110	m	34
111	m or n	34
112-113	n	34
114	n or o	34
115	o	34
116	o or p	34
117-118	p	34
119	p or q	34
120	q	34
121	q or r	34
122-123	r	34
124	r or s	34
125	s	34
126	s or t	34
127-128	t	34
129	t or u	34
130	u	34
131	u or v	34
132-133	v	34
134	v or w	34
135	w	34
136	w or x	34
137-138	x	34
139	x or y	34
140	y	34
141	y or z	34
142-143	z	34
144	z or 2	34 or 35
145-255	2	35

Bech32

Bech32 is a segwit address format specified by BIP 0173 and BIP 0350. This address format is also known as “bc1 addresses”. Bech32 is more efficient with block space. As of October 2020, the Bech32 address format is supported in many popular wallets and is the preferred address scheme.

See the page Bech32 adoption to track adoption.

Examples

Examples of the address format being used on mainnet are the TXIDs 4ef47f6eb681d5d9fa2f7e16336cd629303c635e8da51e425b76088be9c8744c and 514a33f1d46179b89e1fea7bbb07b682ab14083a276979f91038369d1a8d689b. And addresses bc1qar0srrr7xfkvy5l643lydnw9re59gtzzwf5mdq and bc1qc7slrfxkknqcq2jevvvkdgvrt8080852dfjewde450xdlk4ugp7szw5tk9.

Creating a Bech32 address

A Bech32 address is created from a public key as follows:

1. Having a compressed public key (0x02 or 0x03 followed by 32 byte X coordinate): 0279be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798

2. Perform SHA-256 hashing on the public key: 0f715baf5d4c2ed329785cef29e562f73488c8a2bb9dbc5700b361d54b9b0554

3. Perform RIPEMD-160 hashing on the result of SHA-256: 751e76e8199196d454941c45d1b3a323f1433bd6

4. The result of step 3 is an array of 8-bit unsigned integers (base 2^8=256) and Bech32 encoding converts this to an array of 5-bit unsigned integers (base 2^5=32) so we “squash” the bytes to get:

in hex: 0e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16

in numbers: 14 20 15 07 13 26 00 25 18 06 11 13 08 21 04 20 03 17 02 29 03 12 29 03 04 15 24 20 06 14 30 22

5 bits binary: 01110 10100 01111 00111 01101 11010 00000 11001 10010 00110 01011 01101 01000 10101 00100 10100 00011 10001 00010 11101 00011 01100 11101 00011 00100 01111 11000 10100 00110 01110 11110 10110

5. Add the witness version byte in front of the step 4 result (current version is 0): 000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e16

6. Compute the checksum by using the data from step 5 and the H.R.P (bc for MainNet and tb for TestNet) 0c0709110b15

7. Append the checksum to result of step 5 (we now have an array of 5-bit integers): 000e140f070d1a001912060b0d081504140311021d030c1d03040f1814060e1e160c0709110b15

8. Map each value to its corresponding character in Bech32Chars (qpzry9x8gf2tvdw0s3jn54khce6mua7l) 00 -> q, 0e -> w,… qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

9. A Bech32_encoded address consists of 3 parts: HRP + Separator + Data: bc1qw508d6qejxtdg4y5r3zarvary0c5xw7kv8f3t4

The final result from step 9 is the same as example in BIP173.

Base58Check encoding

A modified Base 58 binary-to-text encoding known as Base58Check is used for encoding Bitcoin addresses.

More generically, Base58Check encoding is used for encoding byte arrays in Bitcoin into human-typable strings.

The original Bitcoin client source code explains the reasoning behind base58 encoding:

base58.h:// 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 account numbers. // – A string with non-alphanumeric characters is not as easily accepted as an account number. // – E-mail usually won’t line-break if there’s no punctuation to break at. // – Doubleclicking selects the whole number as one word if it’s all alphanumeric.

Features of Base58Check

Base58Check has the following features:

• An arbitrarily sized payload.
• A set of 58 alphanumeric symbols consisting of easily distinguished uppercase and lowercase letters (0OIl are not used)
• One byte of version/application information. Bitcoin addresses use 0x00 for this byte (future ones may use 0x05).
• Four bytes (32 bits) of SHA256-based error checking code. This code can be used to automatically detect and possibly correct typographical errors.
• An extra step for preservation of leading zeroes in the data.

Creating a Base58Check string

A Base58Check string is created from a version/application byte and payload as follows.

1. Take the version byte and payload bytes, and concatenate them together (bytewise).
2. Take the first four bytes of SHA256(SHA256(results of step 1))
3. Concatenate the results of step 1 and the results of step 2 together (bytewise).
4. Treating the results of step 3 – a series of bytes – as a single big-endian bignumber, convert to base-58 using normal mathematical steps (bignumber division) and the base-58 alphabet described below. The result should be normalized to not have any leading base-58 zeroes (character ‘1’).
5. The leading character ‘1’, which has a value of zero in base58, is reserved for representing an entire leading zero byte, as when it is in a leading position, has no value as a base-58 symbol. There can be one or more leading ‘1’s when necessary to represent one or more leading zero bytes. Count the number of leading zero bytes that were the result of step 3 (for old Bitcoin addresses, there will always be at least one for the version/application byte; for new addresses, there will never be any). Each leading zero byte shall be represented by its own character ‘1’ in the final result.
6. Concatenate the 1’s from step 5 with the results of step 4. This is the Base58Check result.

A more detailed example is provided on the page describing the technical background of the bitcoin address.

Encoding a Bitcoin address

Bitcoin addresses are implemented using the Base58Check encoding of the hash of either:

• Pay-to-script-hash (p2sh): payload is: RIPEMD160(SHA256(redeemScript)) where redeemScript is a script the wallet knows how to spend; version 0x05 (these addresses begin with the digit ‘3’)
• Pay-to-pubkey-hash (p2pkh): payload is RIPEMD160(SHA256(ECDSA_publicKey)) where ECDSA_publicKey is a public key the wallet knows the private key for; version 0x00 (these addresses begin with the digit ‘1’)

The resulting hash in both of these cases is always exactly 20 bytes. These are big-endian (most significant byte first). (Beware of bignumber implementations that clip leading 0x00 bytes, or prepend extra 0x00 bytes to indicate sign – your code must handle these cases properly or else you may generate valid-looking addresses which can be sent to, but cannot be spent from – which would lead to the permanent loss of coins.)

Encoding a private key

Base58Check encoding is also used for encoding ECDSA private keys in the wallet import format. This is formed exactly the same as a Bitcoin address, except that 0x80 is used for the version/application byte, and the payload is 32 bytes instead of 20 (a private key in Bitcoin is a single 32-byte unsigned big-endian integer). For private keys associated with an uncompressed public key, such encodings will always yield a 51-character string that starts with ‘5’, or more specifically, either ‘5H’, ‘5J’, or ‘5K’.

Base58 symbol chart

The Base58 symbol chart used in Bitcoin is specific to the Bitcoin project and is not intended to be the same as any other Base58 implementation used outside the context of Bitcoin (the characters excluded are: 0, O, I, and l).

Value	Character	Value	Character	Value	Character	Value	Character
0	1	1	2	2	3	3	4
4	5	5	6	6	7	7	8
8	9	9	A	10	B	11	C
12	D	13	E	14	F	15	G
16	H	17	J	18	K	19	L
20	M	21	N	22	P	23	Q
24	R	25	S	26	T	27	U
28	V	29	W	30	X	31	Y
32	Z	33	a	34	b	35	c
36	d	37	e	38	f	39	g
40	h	41	i	42	j	43	k
44	m	45	n	46	o	47	p
48	q	49	r	50	s	51	t
52	u	53	v	54	w	55	x
56	y	57	z

The algorithm for encoding address_byte_string (consisting of 1-byte_version + hash_or_other_data + 4-byte_check_code) is code_string = “123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz” x = convert_bytes_to_big_integer(hash_result) output_string = “” while(x > 0) { (x, remainder) = divide(x, 58) output_string.append(code_string[remainder]) } repeat(number_of_leading_zero_bytes_in_hash) { output_string.append(code_string[0]); } output_string.reverse();

Version bytes

Here are some common version bytes:

Decimal version	Leading symbol	Use
0	1	Bitcoin pubkey hash
5	3	Bitcoin script hash
21	4	Bitcoin (compact) public key (proposed)
52	M or N	Namecoin pubkey hash
128	5	Private key (uncompressed pubkey)
128	K or L	Private key (compressed pubkey)
129-135	5, K, L, or M	Private key (Electrum-defined[1] and now deprecated[2])
111	m or n	Bitcoin testnet pubkey hash
196	2	Bitcoin testnet script hash

---