Bitcoin Wiki - User contributions [en]

Invoice address

2015-04-02T05:05:14Z

Friend: Noted Rosetta Code and online tool for address validation.

A '''Bitcoin address''', or simply '''address''', is an identifier of 26-35 alphanumeric characters, beginning with the number 1 or 3, that represents a possible destination for a Bitcoin payment.
Addresses can be generated at no cost by any user of Bitcoin.
For example, using [[Bitcoin-Qt]], one can click "New Address" and be assigned an address.
It is also possible to get a Bitcoin address using an account at an exchange or online wallet service.

An example of a Bitcoin address is <code>3J98t1WpEZ73CNmQviecrnyiWrnqRhWNLy</code>.

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

==Addresses can be created offline==
Creating addresses 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 addresses offline using freely available software tools.
Generating batches of addresses is useful in several scenarios, such as e-commerce websites where a unique pre-generated address is dispensed to each customer who chooses a "pay with Bitcoin" option.
Newer [[Deterministic wallet | "HD wallets"]] can generate a "seed" token which can be used to allow untrusted systems (such as webservers) to generate an unlimited number of addresses without the ability to spend the bitcoins received.

==Addresses are case sensitive and exact==
Bitcoin addresses are case-sensitive. Bitcoin addresses should be copied and pasted using the computer's clipboard wherever possible. If you hand-key a Bitcoin address, and each character is not transcribed exactly - including capitalization - the incorrect 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 address is accepted as being valid is 1 in 232, that is, approximately 1 in 4.29 billion.

==Proving you receive with an address==
Most Bitcoin wallets have a function to "sign" a message, proving the entity receiving funds with an address 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 address for authentication only, in which case the 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 address.

It is important to note that these signatures only prove one receives with an address.
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 addresses (that begin with the number 1).

==Address validation==
If you would like to validate a Bitcoin address in an application, it is advisable to use a method from [https://bitcointalk.org/index.php?topic=1026.0 this thread] rather than to just check for string length, allowed characters, or that the address starts with a 1 or 3. Validation may also be done using open source code available in [http://rosettacode.org/wiki/Bitcoin/address_validation various languages] or with an [http://lenschulwitz.com/base58 online validating tool].

==[[Multisignature|Multi-signature]] addresses==
Addresses can be created that require a combination of multiple private keys.
Since these take advantage of newer features, they begin with the newer prefix of 3 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 address, and once an address is created, the requirement cannot be changed without generating a new address.

==What's in an address==
Most Bitcoin 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 addresses can be shorter than 34 characters (as few as 26) and still be valid.
A significant percentage of Bitcoin addresses are only 33 characters, and some addresses may be even shorter.
Every Bitcoin address stands for a number.
These shorter addresses are valid simply because they stand for numbers that happen to start with zeroes, and when the zeroes are omitted, the encoded address gets shorter.

Several of the characters inside a Bitcoin address 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) address is in fact valid and isn't simply an address with a missing character.

==Testnet==
Addresses on the Bitcoin Testnet are generated with a different address version, which results in a different prefix.
See [[List of address prefixes]] and [[Testnet]] for more details.

==Misconceptions==
===Address reuse===

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===

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 address, minus bitcoins sent in random unrelated transactions'' as an "address balance", but this number is not meaningful: it does not infer the recipient of the bitcoins sent to the address has spent them, nor that they still have the bitcoins received.

==="From" addresses===
Bitcoin transactions do not have any kind of origin-, source- or "from" address. See the dedicated article on "[[From address|from address]]" for more details.

==See Also==
* [[Technical background of Bitcoin addresses]]
* [[List of address prefixes]]
* [[Exit Address]]

== References ==
<references/>

[[Category:Vocabulary]]

[[es:Dirección]]
[[de:Adresse]]

Mini private key format

2015-04-02T04:49:30Z

Friend: No more Mt. Gox.

[[Image:QR-privkeys-sidebyside.png|thumb|right|QR codes of the same private key, in mini versus regular private key format. Both codes have the same dot density and error correction level, but the mini key is 57% of the full code's size.]]
The '''mini private key format''' is a method of encoding a Bitcoin private key in as few as 30 characters so that it can be embedded in a small space. This private key format was first used in Casascius physical bitcoins, and is also favorable for use in QR codes. The fewer characters encoded in a QR code, the lower dot density can be used, as well as more dots allocated to error correction in the same space, significantly improving readability and resistance to damage. The mini private key format offers its own built-in check code as a small margin of protection against typos.

An example key using this encoding is '''S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy'''.

==Usage on a physical bitcoin==
The way it might appear within a physical bitcoin is on a round card printed as follows:

Side of discs showing mini private key: (from [[Casascius physical bitcoins]]) 
[[Image:Miniprivkeys.jpg|300px]]

Side of discs showing prefix of bitcoin address (printed on the opposite side): 
[[Image:Minipubkeys.jpg|300px]]

The examples in this article use the private key and Bitcoin address of the leftmost circle in the above two photos.

==Usage in bar codes==
The mini private key is suitable for use in QR codes. The recommended settings for maximizing readability are: QR version 3, error correction level Q (near highest, 25% possible lost codeword recovery). This results in a 29x29 grid. A minikey QR code can also fit in a 25x25 grid with QR version 2, error correction level L (lowest, 7% possible lost codeword recovery).

The sample private minikey encoded as a QR code on a 29x29 grid looks like this:

[[Image:Private_minikey_in_2D_barcode.gif]]

The mini private key is small enough to fit in a one-dimensional barcode while still remaining practical. Among the most popular one-dimensional barcode symbologies, the one known as "Code 128" is best suited for encoding a minikey due to its favorable data density and support for mixed case strings. The variant known as "Code 128-B" produces the shortest code for strings containing lowercase characters.

The sample private minikey encoded with Code 128-B looks like this:

[[Image:Private_minikey_in_1D_barcode.gif]]

==Import==
Mini private keys can be imported through the following clients/services:

===Applications===
* [[Armory]]

The current mainline ("Satoshi") client cannot currently be used to import minikeys.

===Web===

* [[BlockChain.info]]
** Private keys can be imported into a Blockchain.info wallet and bitcoins can be sent to another address immediately upon import without needing to wait for any confirmations. Even after import, funds remain associated with the private key until they are actually spent to a different address.
* [[StrongCoin]]

==Decoding==
The private key encoding consists of 30 alphanumeric characters from the [[base58]] alphabet used in Bitcoin. The first of the characters is always the uppercase letter S.

To determine whether the minikey is valid:

# Add a question mark to the end of the mini private key string.
# Take the SHA256 hash of the entire string. However, we will only look at the first byte of the result.
# If the first byte is 00, the string is a well-formed minikey. If the first byte is not 00, the string should be rejected as a minikey.

===Example with SHA256===
Here is an example with the sample private key <tt>S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy</tt>.

The string "<tt>S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy?</tt>" has a SHA256 value that begins with 00, so it is well-formed.

To obtain the full 256-bit private key, simply take the SHA256 hash of the entire string. There is no encoding for line breaks in the string, even if the key is broken into multiple lines for printing. The SHA256 should be taken of exactly thirty bytes.

SHA256("S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy") = 4C7A9640C72DC2099F23715D0C8A0D8A35F8906E3CAB61DD3F78B67BF887C9AB

This sample key in [[wallet export format]] is <tt>5JPy8Zg7z4P7RSLsiqcqyeAF1935zjNUdMxcDeVrtU1oarrgnB7</tt>, and the corresponding [[Bitcoin address]] is <tt>1CciesT23BNionJeXrbxmjc7ywfiyM4oLW</tt>.

==== Command line verification ====
To calculate SHA256 from the command line on OSX or Linux devices:

echo -n "S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy?" | shasum -a 256

That should output a line of text like "<tt>000f2453798ad4f951eecced2242eaef3e1cbc8a7c813c203ac7ffe57060355d -</tt>". Since the first two characters are <tt>00</tt> the verification passes for the mini key <tt>S6c56bnXQiBjk9mqSYE7ykVQ7NzrRy</tt>

==Check code==
The mini private key format offers a simple typo check code. Mini private keys must be generated in a "brute force" fashion, keeping only keys that conform to the format's rules. If a key is well-formed (30 Base58 characters starting with S), but fails the hash check, then it probably contains a typo.

If the SHA256 hash of the string followed by '?' doesn't result in something that begins with 0x00, the string is not a valid mini private key.

==Creating mini private keys==
Creating mini private keys is relatively simple. One program which can create such keys is [[Casascius Bitcoin Utility]].

Mini private keys must be created "from scratch", as the conversion from mini private key to full-size private key is one-way. In other words, there is no way to convert an existing full-size private key into a mini private key.

To create mini private keys, simply create random strings that satisfy the well-formedness requirement, and then eliminate the ones that do not pass the typo check. (This means eliminating more than 99% of the candidates.) Then use the appropriate algorithm to compute the corresponding private key, and in turn, the matching Bitcoin address. The Bitcoin address can always be computed from just the private key.

It is strongly advisable to avoid using the digit "1" in minikeys unless it is being printed in such a way where a user is unlikely to mistake it for the lowercase letter "l". Few clients and redemption tools are prepared to tell the user that their entry containing the letter "l" should actually be the number "1" - rather, they will simply reject the code and may leave the user confused.

In all cases, you '''must''' use a secure cryptographic random number generator to eliminate risks of predictability of the random strings.

==Casascius Series 1 coins==

Casascius Series 1 Physical Bitcoins use a 22-character variant of the minikey format, instead of 30 characters. Everything is the same other than the length. To properly implement minikey redemption, services and clients MUST support the 30-character format, but MAY support the 22-character format as well. Use of the 22-character format for future applications is discouraged due to security considerations.

==Python Code==
The following code produces sample 30-character SHA256-based mini private keys in Python. For real-world use, ''random'' must be replaced with a better source of entropy, as the Python documentation for ''random'' states the function ''"is completely unsuitable for cryptographic purposes"''.

<source lang="python">
import random
import hashlib

BASE58 = '23456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz'

def Candidate():
"""
Generate a random, well-formed mini private key.
"""
return('%s%s' % ('S', ''.join(
[BASE58[ random.randrange(0,len(BASE58)) ] for i in range(29)])))

def GenerateKeys(numKeys = 10):
"""
Generate mini private keys and output the mini key as well as the full
private key. numKeys is The number of keys to generate, and
"""
keysGenerated = 0
totalCandidates = 0
while keysGenerated < numKeys:
try:
cand = Candidate()
# Do typo check
t = '%s?' % cand
# Take one round of SHA256
candHash = hashlib.sha256(t).digest()
# Check if the first eight bits of the hash are 0
if candHash[0] == '\x00':
privateKey = GetPrivateKey(cand)
print('\n%s\nSHA256( ): %s\nsha256(?): %s' %
(cand, privateKey, candHash.encode('hex_codec')))
if CheckShortKey(cand):
print('Validated.')
else:
print('Invalid!')
keysGenerated += 1
totalCandidates += 1
except KeyboardInterrupt:
break
print('\n%s: %i\n%s: %i\n%s: %.1f' %
('Keys Generated', keysGenerated,
'Total Candidates', totalCandidates,
'Reject Percentage',
100*(1.0-keysGenerated/float(totalCandidates))))

def GetPrivateKey(shortKey):
"""
Returns the hexadecimal representation of the private key corresponding
to the given short key.
"""
if CheckShortKey(shortKey):
return hashlib.sha256(shortKey).hexdigest()
else:
print('Typo detected in private key!')
return None

def CheckShortKey(shortKey):
"""
Checks for typos in the short key.
"""
if len(shortKey) != 30:
return False
t = '%s?' % shortKey
tHash = hashlib.sha256(t).digest()
# Check to see that first byte is \x00
if tHash[0] == '\x00':
return True
return False
</source>

Technical background of version 1 Bitcoin addresses

2014-09-15T19:16:17Z

Friend: Added link to online address validator and Base58 decode/encode.

[[File:PubKeyToAddr.png|thumb|right|Conversion from ECDSA public key to Bitcoin Address]]
This article may be too technical for some users. The more basic article on [[Address|Bitcoin Addresses]] may be more appropriate.

A [[Bitcoin address]] is a 160-bit hash of the public portion of a public/private [[Wikipedia:Elliptic_Curve_DSA|ECDSA]] keypair. Using [[Wikipedia:Public-key_cryptography|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|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. Normal addresses currently always start with 1 (addresses from script hashes use 3), though this might change in a future version. Testnet addresses usually start with ''m'' or ''n''. Mainline 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 [[Wikipedia:Collision_(computer_science)|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). If you were to intentionally try to make a collision, it would currently take 2^107 times longer to generate a colliding Bitcoin address than to generate a block. As long as the signing and hashing algorithms remain cryptographically strong, it will likely always be more profitable to collect generations and [[transaction fee|transaction fees]] than to try to create collisions.

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==
0 - Having a private [[ECDSA]] key
18E14A7B6A307F426A94F8114701E7C8E774E7F9A47E2C2035DB29A206321725
1 - Take the corresponding public key generated with it (65 bytes, 1 byte 0x04, 32 bytes corresponding to X coordinate, 32 bytes corresponding to Y coordinate)
0450863AD64A87AE8A2FE83C1AF1A8403CB53F53E486D8511DAD8A04887E5B23522CD470243453A299FA9E77237716103ABC11A1DF38855ED6F2EE187E9C582BA6
2 - Perform SHA-256 hashing on the public key
600FFE422B4E00731A59557A5CCA46CC183944191006324A447BDB2D98D4B408
3 - Perform RIPEMD-160 hashing on the result of SHA-256
010966776006953D5567439E5E39F86A0D273BEE
4 - Add version byte in front of RIPEMD-160 hash (0x00 for Main Network)
00010966776006953D5567439E5E39F86A0D273BEE
''(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
445C7A8007A93D8733188288BB320A8FE2DEBD2AE1B47F0F50BC10BAE845C094
6 - Perform SHA-256 hash on the result of the previous SHA-256 hash
D61967F63C7DD183914A4AE452C9F6AD5D462CE3D277798075B107615C1A8A30
7 - Take the first 4 bytes of the second SHA-256 hash. This is the address checksum
D61967F6
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.
00010966776006953D5567439E5E39F86A0D273BEED61967F6
9 - Convert the result from a byte string into a base58 string using [[Base58Check encoding]]. This is the most commonly used Bitcoin Address format
16UwLL9Risc3QfPqBUvKofHmBQ7wMtjvM

==See Also==
* [[Address]]
* [[Base58Check encoding]]
* [http://gobittest.appspot.com/Address Address testing suite]
* [http://lenschulwitz.com/base58 Online Address Validator and Base58 Encoder/Decoder]

[[Category:Technical]]

Base58Check encoding

2014-09-15T19:09:21Z

Friend: Added link to Base58 Encode/Decode online tool and Perl code.

A modified Base 58 [http://en.wikipedia.org/wiki/Binary-to-text_encoding binary-to-text encoding] known as '''Base58Check''' is used for encoding [[Bitcoin address|Bitcoin addresses]].

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

==Background==
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.
# Take the version byte and payload bytes, and concatenate them together (bytewise).
# Take the first four bytes of SHA256(SHA256(results of step 1))
# Concatenate the results of step 1 and the results of step 2 together (bytewise).
# 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').
# 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.
# Concatenate the 1's from step 5 with the results of step 4. '''This is the Base58Check result.'''

==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 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 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 [[private key|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.
{| class="wikitable"
|-
!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:

{| class="wikitable"
|-
!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
|-
|111
|m or n
|Bitcoin testnet pubkey hash
|-
|196
|2
|Bitcoin testnet script hash
|}
[[List of address prefixes]] is a more complete list.

== See Also ==
* [http://lenschulwitz.com/base58 Online Base58 Decoder, Encoder, and Validator]

== Source code ==
* [https://github.com/bitcoin/bitcoin/blob/master/src/base58.h "Satoshi" C++ codebase (encode/decode using BigNum library)]
* [https://github.com/luke-jr/libbase58 libbase58 C code (decode and encode, no external libraries needed)]
* [https://gitorious.org/bitcoin/libblkmaker/blobs/master/base58.c libblkmaker C code (decode only, no external libraries needed)]
* [http://lenschulwitz.com/b58/base58perl.txt Base58 Decode, Encode, and Validate in Perl]

[[Category:Technical]]

[[es:Codificación Base58Check]]